test(env): hold both DEPLOYMENT_SUITE values in one test, not two - #37

Closes #36.

vm.setEnv writes the forge PROCESS' environment. It is scoped to neither a
test nor a contract, no cheatcode unsets or restores it, and forge runs tests
concurrently — so two tests holding two values for one variable is two tests
racing over one variable. RainDeployBroadcastTest was exactly that, and was
seen losing the race: the unset case resolved the address-registry the other
test had written.

[FAIL: Error != expected error:
 UnknownDeploymentSuite("address-registry", "address-registry-0-0-1, second-address, address-registry-candidate")
 != UnknownDeploymentSuite("", "address-registry-0-0-1, second-address, address-registry-candidate")]
 testRunUnsetSuiteReverts()

The fix

The two values are sequenced inside ONE test, which is the only ordering forge
guarantees, and every vm.setEnv in the repo is now in that one test — the
DEPLOYMENT_SUITE write after the only read that needs it absent, so there is no
write left for another test to observe. Nothing else in the repo reads
DEPLOYMENT_SUITE or DEPLOYMENT_KEY: the only reader is run(), and the only
caller of run() is this test.

There is no smaller fix. Foundry offers no scoped or restorable env: setEnv is
std::env::set_var on the process, and unsetEnv does not exist. Making the
value injectable instead would remove the only assertion that the value comes
from a variable of THAT name (killed as M2 below), and serialising the suite with
--threads 1 would trade the whole suite's parallelism to leave the sharing in
place.

The two variables are not the same problem

DEPLOYMENT_SUITE has to be genuinely ABSENT, and that is the assertion doing
the work. vm.setEnv("DEPLOYMENT_SUITE", "") set a variable that was PRESENT and
empty, so vm.envOr's default was never reached and a default that silently
became a real suite key passed — the exact hazard that test's own comment names,
"a deploy that picks something when told nothing". Nothing in CI sets that
variable (checked: neither rainix-sol-test nor this repo's caller workflow), so
assertFalse(vm.envExists("DEPLOYMENT_SUITE")) holds and states the precondition
by name.

DEPLOYMENT_KEY is the opposite: absence is not this test's to give.
rainix-sol-test sets DEPLOYMENT_KEY: ${{ secrets.PRIVATE_KEY }} on the job
that runs this suite, so it is present everywhere the test really runs. So the
test SETS it, to something vm.envUint cannot parse. That is a stronger oracle
than absence, not a weaker one: the ordering claim is "the suite was resolved
before the key was read", and a key that PARSES makes both orderings produce the
same revert — so under CI's own key, asserting absence would have discriminated
nothing about ordering even if it had passed. Unreadable-by-construction makes
M3 die in every environment.

Mutation matrix

forge test --match-path test/src/abstract/RainDeployBroadcast.t.sol --match-test testRunSelectsTheSuiteFromTheEnvBeforeTheKeyAndNeverDefaults,
run under each ambient DEPLOYMENT_KEY state the suite meets — unset (bare
shell), set to a valid key (CI with the secret populated), set to empty (CI with
the secret absent, which still exports the variable):

M1 and M3 fail with Error != expected error: vm.envUint: failed parsing $DEPLOYMENT_KEY as type uint256: parser error != UnknownDeploymentSuite("", ...);
M2 with UnknownDeploymentSuite("", ...) != UnknownDeploymentSuite("address-registry", ...).

Two more results from the same matrix:

• M1 run against the tests as they were BEFORE this PR: testRunUnknownSuiteRevertsBeforeReadingTheKey
  and testRunUnsetSuiteReverts both PASS. A deploy script that picks a real
  suite when told nothing survived the old suite; it is killed here.
• The first commit on this branch, run under a set DEPLOYMENT_KEY, reproduces
  the CI red exactly — [FAIL: assertion failed] ... (gas: 3980), the same gas
  figure as the failing job
  — and passes in a bare shell. That is the whole of the CI failure, confirmed
  rather than assumed: the -vvv trace shows both VM::envExists calls followed
  by one VM::assertFalse(true), i.e. the DEPLOYMENT_KEY assertion.

forge fmt --check passes. forge test --no-match-contract Chain on this branch,
run with DEPLOYMENT_KEY set as CI sets it, is 92 passed / 38 failed where all 38
are vm.createSelectFork: environment variable *_RPC_URL not found in
LibRainDeployTest — what #32 is about and #34 fixes. This branch changes one
file and it is not that one.

QA

• Discriminating tests: testRunSelectsTheSuiteFromTheEnvBeforeTheKeyAndNeverDefaults
  — passes unmutated (M0) and fails under each of M1, M2 and M3, in all three
  ambient DEPLOYMENT_KEY states (unset, valid, empty): 12 runs, one per cell of
  the matrix above. Each is its own forge test --match-path test/src/abstract/RainDeployBroadcast.t.sol --match-test <name> with the [PASS] / [FAIL: ...] line captured, so every
  cell is a run that actually selected and executed the test rather than a filter
  matching nothing. The two tests this PR does not touch —
  testDeployNetworksDefaultsToSupportedNetworks, testSelectedSuiteCarriesTheRecordedPins
  — are unchanged.
• Mutations applied (all in src/abstract/RainDeployBroadcast.sol, the code
  under test; killer is the test above in every case, in every environment):
  • M1 — vm.envOr("DEPLOYMENT_SUITE", string("")) → string("address-registry-0-0-1")
    → KILLED: vm.envUint: failed parsing $DEPLOYMENT_KEY as type uint256 != UnknownDeploymentSuite("", ...).
    This mutant SURVIVES the pre-PR tests — testRunUnknownSuiteRevertsBeforeReadingTheKey
    and testRunUnsetSuiteReverts both PASS under it. That gap is what the new
    test closes.
  • M2 — "DEPLOYMENT_SUITE" → "DEPLOYMENT_SUIT" → KILLED:
    UnknownDeploymentSuite("", ...) != UnknownDeploymentSuite("address-registry", ...).
  • M3 — uint256 deployerPrivateKey = vm.envUint("DEPLOYMENT_KEY"); moved above
    the suiteByName(...) line → KILLED: vm.envUint: failed parsing $DEPLOYMENT_KEY as type uint256 != UnknownDeploymentSuite("", ...).
    Killed under a VALID ambient key too, which is the case that matters: this
    mutant is invisible to any test that lets a parseable key reach envUint,
    because then both orderings revert identically.
• Oracle: the workflow's contract with the script, not the implementation.
  Manual sol artifacts hands the script a suite key as DEPLOYMENT_SUITE and key
  custody as DEPLOYMENT_KEY, so the expected behaviour is fixed independently of
  the code: the key the caller passed is the key reported back, passing no suite
  selects no suite, and neither answer requires a usable private key. The
  valid-suite list in the expected payload is the fixture's own declaration
  (ExampleDeploySuites), asserted separately by
  RainDeploySuitesBaseTest.testSuiteNamesIsTheRegistry.
• Category check: Flaky suite: two tests write the process-global DEPLOYMENT_SUITE, so one reads the other's value #36 asks for the shared vm.setEnv state removed without
  either assertion getting weaker, and names the three behaviours the result must
  still discriminate — the envOr default becoming a suite key, the variable name
  changing, and the key being read before the suite. Covered by M1, M2 and M3
  respectively, plus the sharing itself: every vm.setEnv in the repo is in this
  one test, with the DEPLOYMENT_SUITE write after the only read that needs it
  absent.